Within a computer processing environment, an interrupt, as the name implies, is some event which interrupts normal program execution. That is, programs execute on a microprocessor sequentially, being altered only by those instructions which expressly cause program flow to deviate in some way (e.g., jump instructions, branch instructions, etc.) Interrupts, on the other hand, give system designers a mechanism to “put on hold” normal program flow, for the purpose of executing a special program called an interrupt handler, and then allows the processor to resume normal program flow as if it had never been interrupted. The interrupt handler is only executed when a certain event (interrupt) occurs. The event may be a timer overflowing, or a serial port transmitting a character. By providing the ability to interrupt normal program execution, certain events such as those mentioned above are much easier and more efficient to handle than requiring the microprocessor to periodically execute special programs.
Referring to FIG. 1, a block diagram is provided that will help illustrate how interrupts are handled within a prior art processing environment. The environment 100 includes a microprocessor 102, coupled to an interrupt controller 110 and memory 120. The microprocessor contains a core 104 for executing instructions retrieved from the memory 120. In addition, the core 104 produces a number of interrupts 106, including both software interrupts and hardware interrupts (e.g., timer overflow) that must be “handled” by the microprocessor 102, as will be further described below with reference to FIG. 2. The microprocessor 102 further includes a cause register 108 for indicating to the microprocessor 102 the cause or source of an interrupt.
The interrupt controller 110 is coupled to a number of external devices 118 via interrupt lines 116, and to other system interrupts 114. The interrupt controller 110, orders the interrupts 110 to provide them to the microprocessor 102 via interrupt lines 112. One skilled in the art will appreciate that early microprocessors 102 were provided with a preset number of interrupt lines 112 for use by system level designers. However, as the need for interrupts increased, rather than adding additional pins on the microprocessor, interrupt controllers 110 were provided to interface between the increased number of interrupts 114, 116, and the existing interrupt lines 112 on the microprocessor 102.
The microprocessor 102 is connected to the memory 120, to retrieve instructions for execution, as mentioned above, and to retrieve information relating to interrupts, such as an interrupt vector table 122, and to retrieve the programs which handle the interrupts 124.
Referring now to FIG. 2, a flow chart 200 is shown that illustrates prior art program flow when an interrupt occurs within the microprocessor 102. Operation of the program flow for handling interrupts will now be described with reference to both FIGS. 1 and 2.
Program execution begins at block 202 and proceeds to block 204.
At block 204, instructions are executed by the microprocessor 102 that are retrieved from memory 120. Flow then proceeds to decision block 206.
At decision block 206, a determination is made by the microprocessor 102 as to whether an interrupt has occurred, either by the core 104, or by the interrupt lines 112. Although not shown, the microprocessor 102 includes logic that detects and latches an interrupt when it occurs, thereby alerting the microprocessor 102 of the interrupt. The state of the latches is typically checked by the microprocessor 102 between every instruction execution. If no interrupt has occurred, flow proceeds back to block 204 where the microprocessor 102 continues to execute instructions. However, if an interrupt occurs, flow proceeds to block 208.
At block 208, the microprocessor 102 ceases execution of the current program instructions, and jumps to a special program called an interrupt handler (or exception handler), such as interrupt handler #1 124. Flow then proceeds to block 210.
At block 210, the interrupt handler reads the cause register 108 to determine what kind of interrupt occurred. Flow then proceeds to block 212.
At block 212, the interrupt vector table 122 is read to determine which interrupt handler 124 should be used for the type of interrupt indicated in the cause register 108. When determined, the microprocessor 102 jumps to a particular interrupt handler routine 124 specific to the type of interrupt indicated in the cause register 108. One skilled in the art will recognize that methods other than an interrupt vector table may be used to determine which interrupt handler should be used. Flow then proceeds to block 214.
At block 214, the interrupt is handled by the particular interrupt handler routine 124 that was jumped to. Flow then proceeds to block 216.
At block 216, the interrupt handler 124 returns program flow back to block 204 to continue execution of the program that was executing when the interrupt occurred.
One skilled in the art will appreciate that the above description of the microprocessor system 100, and the interrupt handling flow chart 200 is very general. That is, the description has ignored more complex aspects of interrupt handling, such as what occurs when multiple interrupts occur at the same time, or when an interrupt occurs during handling of another interrupt, or how multiple interrupts are prioritized, etc. However, the above is sufficient to illustrate that: 1) interrupts can occur from sources that are both internal and external to the microprocessor 102, that the microprocessor 102 must have some mechanism for prioritizing interrupts when multiple interrupts occur at approximately the same time, and that one method that has been utilized in the prior art requires an interrupt handler to query a cause register 108 within the microprocessor 102 to determine the type of interrupt that has occurred, before it can decide which interrupt handler routine is appropriate to handle the interrupt.
For interrupts that do not require immediate processing, the time required to jump to a general exception handler, such as that described above with reference to block 208, to determine the cause of the interrupt, and the memory vector for the specific interrupt routine that is required, is not critical. Thus, if it takes 20-50 clock cycles, for example, to determine that the cause of the interrupt is a floppy disk controller indicating that it is ready to write data, the delay relating to determining the type of interrupt is inconsequential.
However, in many instances the delay associated with determining the type of interrupt (as illustrated in FIG. 2) is unacceptable. In such instances, it is common to provide interrupt vectors to a subset of all interrupts, via hardware. That is, interrupts that require immediate processing are attached to one of the first two interrupt lines 112, for example. When an interrupt occurs on one of these lines, the interrupt vector for that line is provided immediately to the microprocessor 102 (via hardware within the microprocessor), causing the microprocessor to jump immediately to the proper interrupt routine (at block 212), rather than the general routine (at block 208).
Direct mapping of high priority interrupts to particular interrupt vectors has allowed certain interrupts to be handled quickly, while allowing programmers to specify how other lower priority interrupts are handled via the general interrupt handler. However, such direct mapping is typically static, for a given processor architecture. That is, such mapping does not allow a system designer to define high/low priorities for particular implementations, nor does it allow the system designer to establish their own vectors for particular processor generated interrupts. In addition, the previous solutions have not allowed a designer to establish selective priorities for core generated interrupts that merge with off processor interrupts.
Therefore, what is needed is a mechanism that allows a system designer to establish interrupt priorities for both core generated, and off-core generated interrupts.
Moreover, what is needed is a mechanism for programmably prioritizing core generated interrupts within a system level interrupt architecture.